我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。

為什麼 AI 上 Production 後，開始需要 Kubernetes？

Day 19 我談到 Docker Image 做好，為什麼還不能直接上 Production？即使Docker Image 做好，並不代表 AI Service 已經準備好 Production。

那麼下一個問題就是：如果一個 Container 不夠了，誰來管理它？

如果今天只是自己測試，一個 Docker Container 跑起來可能就已經足夠。但當 AI Service 開始真正面對使用者，問題會開始增加。如果 Container 只是單一個服務，當它需要多人使用、故障恢復、更新與擴展時，誰來管理這些 Container？

Container 掛掉怎麼辦？需要同時執行多個 Instance 時怎麼辦？流量增加時要不要增加服務數量？更新版本時，能不能降低服務中斷的風險？

我自己從 Docker 一路接觸到 Kubernetes 後，開始理解 Kubernetes 真正吸引我的地方，不只是「可以跑 Container」，而是它開始替我們管理 Container 的生命週期與 Desired State。

Kubernetes Deployment 可以管理多個 Pod 副本，而 Service 則提供穩定的網路端點，讓使用者不需要直接知道背後究竟是哪一個 Pod 在處理請求。當 Pod 發生變化時，Service 仍然可以作為對外的入口。

這讓我開始理解：

Docker 解決的是「怎麼把 AI Application 打包」，而 Kubernetes 開始處理的是「怎麼讓這些 Application 持續運作」。

而到了 AI Inference，還會進一步遇到 GPU 資源、Latency、Throughput、Scaling 與成本等問題。Google Cloud 現行 GKE AI 文件也把 Deployment、Service、Scaling 與 Monitoring 視為 AI inference deployment 的重要環節。Google Cloud 目前的 GKE AI inference 文件也是把 Deployment、Service、Scaling、Monitoring 串在一起；Kubernetes Deployment 負責管理多個 Pod，而 Service 則提供穩定的網路端點，即使背後的 Pod 會被建立、刪除或替換。

Google Cloud 目前針對 GPU 上的 LLM inference，已經提供 HPA 自動調整 Pod replicas 的做法，而且可以使用 queue size、batch size、latency 等 inference-specific metrics。Google Cloud 對 AI inference 的官方架構也是朝這個方向：Deployment 管理模型服務、Service 提供入口，再透過 autoscaling 根據需求調整資源。

所以問題來了：

當一個 AI Demo 從「我自己跑」變成「很多人要使用」，我們真的還能只靠 Docker 管理它嗎？

AI 上 Production 過程中遇到的問題，這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》接下來開始深入 Kubernetes 與 AI Deployment 的原因。

關於作者

我是一名 AI × Infrastructure Solution / Integration 技術實作者，專注於 AI、MLOps、Cloud、Docker、Kubernetes、GPU、LLM 與 AI Agent 等技術的整合與落地，跨足 LLM、GPU、Docker、Kubernetes、MLOps 與 AI Agents，持續研究企業 AI 從 Prototype 到 Production 所需要的工程能力。協助企業理解 AI 從 Prototype 到 Production 所需要的技術能力。

本系列同時是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》的延伸實戰筆記。如果想完整理解這些更深的技術問題，未來可以去看這本書(書中包含了一些的範例與提示詞，特別是AMD W7900 48G的使用技術心得，這些是外面很少有的獨家踩坑經驗，未來買書真的賺到！)。敬請期待唷~ 關於永久網站也有了，正在準備了~